% small.tex
\documentclass{beamer}
\usetheme{default}
\begin{document}

\begin{frame}{A sample slide}
Live Streaming
• Alcune applicazioni aggiungono alle caratteristiche viste in 
precedenza la necessità di campionare, produrre e distribuire il 
media in maniera live
• Il media non è quindi già disponibile, ma viene prodotto o 
(emesso on line) dal mondo reale, per consentire l’accesso ad 
un evento in corso:
• Internet Radio e Internet TV
• VideoConferenza
\end{frame}

\begin{frame}{A sample slide}
Le applicazioni di streaming sono tipicamente basate sui 
seguenti protocolli:
• Protocolli per le trasmissioni multimediali real time che sfruttano 
TCP, ma preferibilmente UDP: Real Time Protocol (RTP)/ Real
Time Control Protocol (RTCP) - RFC 1889 
• Un protocollo per il controllo dell’attività di streaming Real Time 
Streaming Protocol (RTSP - RFC 2326) che fornisce:
 Compressione e decompressione
 Rimozione del Jitter
 Correzione degli errori
\end{frame}

\begin{frame}{A sample slide}
RTSP: Caratteristiche del Protocollo
• protocollo text-based
• protocollo transport independent
• simile all’HTTP con numerose differenze:
• Richieste sia di tipo client  server che di tipo  server 
 client
• Il server mantiene lo stato della sessione
• Usa una comunicazione fuori banda per i segnali di 
controllo
• Opera sia unicast che multicast
\end{frame}

\begin{frame}{A sample slide}
RTSP: Principali Funzionalità
• Supporto per il controllo dell’erogazione in streaming del flusso 
da parte dell’applicazione (tra client e server)
• Supporto per il controllo del flusso da parte dell’utente: 
rewind, fast forward, pause, resume, etc. 
• Gestione delle conferenze: invito, registrazione e rilascio della 
conferenza
\end{frame}

\begin{frame}{A sample slide}
Meta File
• La richiesta avviene tramite il Web, ovvero come richiesta 
HTTP da un browser ad un HTTP server, che avvia la 
comunicazione di streaming tra client e server:
• Il Web browser richiede una risorsa che in realtà è un meta file, 
ovvero un file che descrive il media di cui verrà fatto lo streaming
• Il Server HTTP risponde inviandolo
• Il Browser lancia l’appropriato Player e gli passa il metafile
• Il Player seguendo le indicazioni del Metafile avvia lo streaming
\end{frame}

\begin{frame}{A sample slide}
Classici sistemi di streaming sono:
• RealNetworks
• Microsoft Windows Media Technologies 
• Apple Quicktime (Darwin Streaming Server)
\end{frame}

\begin{frame}{A sample slide}
Applicazioni
• I sistemi disponibili hanno caratteristiche simili:
• Streaming audio e video
• Adattività alla larghezza di banda disponibile
• Scalabilità rispetto al numero di client collegati
• Protocolli standard RTP e RTSP oppure HTTP
• Alcune migliaia di stream contemporanei
• Supporto sia unicast che multicast
• Spesso, ogni sistema ha il suo formato per lo stream
(per cui non esiste interoperabilità)
• Real e Quicktime sono multipiattaforma, Windows 
Media è per Windows
\end{frame}

\begin{frame}{A sample slide}
Real Time interattivo su IP
• Alcune delle applicazioni viste nella lezione precedente (e.g., 
semplice download di file multimediali) non richiedono il 
rispetto di requisiti stringenti sui ritardi (e dunque, tra l’altro, 
sulla lunghezza del buffer)
• In caso di audio/video conferenza su Internet (uno a uno, o uno 
a molti) è invece fondamentale che il ritardo complessivo resti 
entro una soglia, senza per questo aumentare le perdite di 
pacchetti
\end{frame}

\begin{frame}{A sample slide}
Caratteristiche dei media 
• Per alcune di queste applicazioni si può sfruttare il fatto che il 
media ha caratteristiche specifiche, che richiedono minore 
larghezza di banda:
• AUDIO = PARLATO, come abbiamo visto copre un sottoinsieme 
dell’udibile che va (circa) da 600 Hz a 5 KHz
• VIDEO = VIDEO LENTO, caratterizzato da un frame rate di 10 
fotogrammi al secondo circa
\end{frame}

\begin{frame}{A sample slide}
Caratteristiche dei media
• Ovviamente, il trade-off tra pacchetti persi e ritardo deve essere 
gestito con molta attenzione
• Ad es. per il parlato, la qualità minima accettabile in termini di:
• Numero di pacchetti persi
• Ritardo
può essere definita da una scala che prevede 3 livelli di qualità
considerata accettabile (ottima, buona, povera)
\end{frame}

\begin{frame}{A sample slide}
Caratteristiche dei media
• Tipicamente, per questo tipo di applicazione vengono aperti 
canali sincroni interattivi di tipo full duplex
• Questo significa che devono essere previsti meccanismi di 
sincronizzazione tra la comunicazione (ovviamente 
unidirezionale) tra sorgente e destinazione) e quella inversa (di 
nuovo unidirezionale), tra destinazione e sorgente
\end{frame}

\begin{frame}{A sample slide}
Migliorie per lo streaming
• Rispetto ai meccanismi di streaming visti fino ad ora, per le 
applicazioni real time di tipo interattivo (videoconferenza), 
sono messe in opera in numerose  migliorie, tra cui:
• Riduzione del processing delay alla sorgente ed alla destinazione
• Gestione del silenzio
• Compensazione dell’eco
• Adattività del livello di compressione
• Adattività del buffer
• Tecniche di recovery dagli errori
\end{frame}

\begin{frame}{A sample slide}
Riduzione del processing delay
• E’ possibile diminuire il processing delay:
• Via software: utilizzando sistemi operativi real time
• Via hardware: utilizzando hardware dedicato per campionare e 
comprimere il flusso multimediale (audio)
• Sono diponibili sul mercato schede ad hoc di tipo DSP, Digital
Signal Processing, che integrano gli algoritmi di campionamento 
e di compressione

\end{frame}



\begin{frame}{A sample slide}
Gestione del silenzio
• Circa il 60% di una comunicazione verbale full duplex è silenzio
• Il silenzio può essere rilevato ed eliminato (inutile trasmettere 
pacchetti che contengono solo rumore bianco)
• Il rumore di fondo va comunque ricostruito al ricevente perché
l’assenza di playout può far pensare all’utente a una 
interruzione del servizi
\end{frame}

\begin{frame}{A sample slide}
Gestione dell’eco
• In una comunicazione full duplex sono presenti fenomeni di eco
• ESEMPIO: quando si utilizzano le casse, il playout del messaggio
del mittente viene ricampionato al ricevente e spedito di nuovo 
al mittente, che sente la sua stessa voce con un certo ritardo
• L’eco deve essere eliminato (via HW oppure via SW)
\end{frame}

\begin{frame}{A sample slide}
Modulazione della compressione
• Il sistema (alla sorgente) stima la larghezza di banda disponibile 
e inizia la trasmissione codificando e comprimendo utilizzando 
un livello di compressione adeguato
• Nel caso la larghezza di banda diminuisca, o aumenti, il sistema
attiva un codec differente e “avverte” il sistema client che “si 
allinea”
\end{frame}

\begin{frame}{A sample slide}
Alcuni codec per l’audio
• Ad esempio, alcuni codec audio (standard ITU) molto utilizzati 
sono:
• G.726 (0.125 microsecondi) adaptive differential pulse-code 
modulation (ADPCM): 16, 24, 32, 40 kbps.
• G.729 (10 millisecondi) CS–ACELP: 8 kbps.
• G.723.1 (30 millisecondi) Multirate Coder: 5.3, 6.3 kbps.
• In alternativa, sono disponibili codec ( basati su Wavelet) in grado 
di variare il proprio livello di compressione
\end{frame}

\begin{frame}{A sample slide}
Adattabilità del buffer
• Tipicamente la lunghezza del buffer viene definita ad inizio 
comunicazione e rimane inalterata finché la comunicazione non 
è conclusa 
• Si possono verificare due diversi tipi di fenomeni che procurano
perdita di pacchetti:
• Buffer underflow (trattato nella precedente lezione): i pacchetti 
arrivano troppo tardi per essere mandati in playout (la loro 
posizione nel buffer non e’ “più disponibile”)
• Buffer overflow I pacchetti arrivano troppo presto per essere 
memorizzati nel buffer, ovvero la loro locazione non e’ “ancora 
disponibile”

\end{frame}

\begin{frame}{A sample slide}
Adattività del buffer
• Questi problemi possono determinarsi causa il fatto che le 
prestazioni della rete (variabili nel tempo) possono cambiare
(rispetto a quanto fissato all’inizio della comunicazione)
• In meglio:  === overflow
• In peggio: === underflow
• Alcuni algoritmi reagiscono prevedendo che la dimensione del 
buffer si adatti dinamicamente alle prestazioni della ret
\end{frame}

\begin{frame}{A sample slide}
Adattività del buffer
• Se la rete cambia nel tempo  la velocità con cui consegna i 
pacchetti all’applicazione, allora il ritardo di playout (e la 
dimensione de buffer) deve potersi:
• Accorciare: le prestazioni della rete sono migliorate e si vuole 
ridurre il ritardo (mantenendo possibilmente inalterato il numero 
di pacchetti persi)
• Allungare: le prestazioni della rete sono peggiorate e il numero 
dei pacchetti persi ha superato la soglia tollerabile. Si vuole 
diminuire il numero dei pacchetti persi a discapito del ritardo (che 
ovviamente aumenterà)
\end{frame}

\begin{frame}{A sample slide}
Allungare il buffer
• Per allungare il buffer occorre:
• Individuare un silenzio nella conversazione
• Inserire (al lato ricevente)  nel playout un silenzio fittizio che 
consenta di aumentare il tempo di attesa per l’ascolto
• Allungare e riallineare il buffer (al lato ricevente)
• Se la comunicazione è full duplex, deve essere riallineata anche 
l’applicazione dall’altro lato
\end{frame}

\begin{frame}{A sample slide}
Accorciare il buffer
• Per accorciare il buffer occorre:
• Individuare un silenzio nella conversazione 
• Eliminarlo (al lato ricevente) nel playout 
• Accorciare e riallineare il buffer (al lato ricevente)
• Se il silenzio individuato non è sufficiente a coprire il taglio alla 
lunghezza del buffer, il procedimento può essere distribuito su 
più silenzi consecutivi
• Se la comunicazione è full duplex, deve essere riallineata anche 
l’applicazione dall’altro lato
\end{frame}

\begin{frame}{A sample slide}
Recovery dei pacchetti persi
• Il recovery dei pacchetti persi può essere fatto con approcci 
differenti:
• Tecniche di correzione al ricevente (e.g., ripetizione o 
interpolazione, già discusse)
• Forward error correction
• Low quality redundant stream
• Interleaving
\end{frame}

\begin{frame}{A sample slide}
Forward error correction
• Forward error correction: l’host sorgente invia, oltre ai 
pacchetti che codificano i dati multimediali, alcuni pacchetti 
aggiuntivi, che in caso di perdite consentono la ricostruzione 
dei dati non arrivati
• I pacchetti aggiuntivi correggono errori avvenuti su n pacchetti 
precedenti
• L’host trasmette un numero di pacchetti superiore al 
“normale”
• Ovviamente perdite multiple consecutive annullano l’efficacia 
del meccanismo
\end{frame}

\begin{frame}{A sample slide}
Low quality redundant stream
• Low quality redundant stream: ogni pacchetto contiene, oltre 
ai dati multimediali dello slot corrente, anche versioni a minore 
qualità di alcuni degli slot precedenti
• L’host trasmette pacchetti di dimensioni maggiori a quanto 
strettamente necessario
• Nonostante questo meccanismo, possono esserci perdite 
multiple di pacchetto non recuperabili
\end{frame}

\begin{frame}{A sample slide}
Interleaving
• Interleaving: alcuni slot consecutivi vengono partizionati e 
ricombinati in pacchetti contenenti parti di diversi slot
• In questo modo se un pacchetto è perso vengono perse porzioni 
molto piccole di ciascuno slot, ricostruibili con tecniche di 
ripetizione o interpolazione
\end{frame}

\end{document}
